Siemens and Rockwell have both been shipping AI-assisted coding features into their flagship IDEs, and the pitch is the same one that swept through general software development a few years back: describe what you want, get working code, spend your time reviewing instead of typing. In TIA Portal and in the newer Studio 5000 add-ins, that means natural-language prompts turning into structured text blocks, auto-generated fault handling routines, tag naming suggestions, and comment blocks written for you instead of by you.
None of this is inherently reckless. But PLC code isn’t a web form or a CRUD app. It runs machines that can crush, burn, or amputate, and a subtle logic error doesn’t throw a stack trace — it just does the wrong thing, quietly, until someone gets hurt or a batch gets scrapped. The industry does not yet have an agreed-upon validation methodology for AI-generated control logic. IEC 62443 governs security. IEC 61508 and machine safety standards govern functional safety. Neither was written with an LLM-in-the-loop code generator in mind, and neither vendor is claiming their assistant discharges your safety validation obligations. That gap between adoption speed and review maturity is the actual story here, and it’s on control engineers to close it themselves, project by project, until something more formal exists.
What these tools are actually good at
Used correctly, AI code assist earns its keep in a fairly narrow but real band of work — the parts of a project that are tedious, repetitive, and low-consequence if slightly wrong.
- Tag naming and organization. Getting a consistent naming convention across a large I/O list, cross-referencing against an existing tag database, or proposing UDT member names based on a description — this is exactly the kind of pattern-matching work an LLM does well, and errors here are cosmetic, caught immediately at compile or by a human reading a screen.
- Comment and documentation generation. Auto-generating rung comments or structured text header blocks from existing logic saves real time and the failure mode is “vague comment,” not “unsafe machine behavior.”
- Boilerplate fault handling scaffolding. A first draft of a standard fault-word structure, alarm class mapping, or HMI fault message table gives you a starting skeleton faster than building it from scratch — as long as you treat it as a skeleton, not a finished interlock system.
- Code explanation and onboarding. Asking the assistant to explain what an unfamiliar block of legacy structured text does is genuinely useful for a new engineer inheriting someone else’s program, and a wrong explanation here just costs you time, not safety.
Notice the common thread: in every one of these cases, a mistake is either self-evident or low-stakes. That’s the test that should govern where you let the tool run ahead of you.
Where it gets dangerous, and why
The failure modes that matter aren’t syntax errors — the compiler catches those. They’re logically valid programs that do the wrong thing under conditions the prompt didn’t specify and the model didn’t reason through, because it has no model of your machine, your process, or your hazard analysis. It has a model of what plausible-looking control code tends to say.
Interlock completeness
Ask an assistant to “generate an interlock so the conveyor won’t run if the guard is open” and you’ll likely get correct logic for exactly that one condition. What you won’t reliably get, unless you ask for it explicitly, is the interlock behaving correctly during a fault state of the guard sensor itself, during PLC scan startup with unknown initial tag values, or in combination with an e-stop already latched. AI-generated interlocks tend to be scenario-complete, not state-complete — they handle the case you described and miss the cases you didn’t think to describe, which is precisely the population of cases that hurts people.
Race conditions across scan cycles
Structured text generated to “look right” often assumes a level of determinism about execution order and timing that doesn’t match how your scan cycle, task priorities, or multiple program organization units actually interact. An LLM has no visibility into your project’s task configuration, your communication latencies, or which other routines write to the same tags. Two independently-generated, individually-correct blocks can create a race condition the moment they’re both dropped into the same scan without a human checking execution order and shared-memory access.
Silent assumption of “normal” operating conditions
Generated code has a bias toward the happy path because that’s what’s overrepresented in training data and in the prompt itself. Real plant logic spends most of its complexity on the unhappy path — sensor dropout, network blip, operator override, partial e-stop recovery, power-cycle mid-cycle. That’s exactly the part a prompt rarely specifies in full, and exactly the part where the assistant will confidently fill gaps with something plausible but untested against your actual failure modes.
A review checklist that actually fits the risk
Treat AI-generated logic the way you’d treat code from a capable but brand-new engineer who has never seen your plant: promising, worth using, not to be trusted unsupervised near anything that moves.
- Classify before you generate. Decide up front whether the block you’re asking for touches safety-related control functions, interlocks, or anything SIL/PL-rated. If it does, AI-assisted drafting is fine; AI-assisted sign-off is not.
- Demand the full state table, not just the prompt scenario. For any interlock or permissive logic, explicitly enumerate every input state combination you expect, including sensor fault and power-up states, and check the generated code against all of them — not just the one you described.
- Check execution order and shared tags by hand. Never assume generated logic understands your task configuration, scan priorities, or which other routine touches the same tag. This has to be traced manually against the actual project.
- Run it through your existing FAT/SAT and simulation process unchanged. AI-generated code doesn’t get an exemption from factory acceptance testing, and if your simulation environment (PLCSIM, Studio 5000 Emulate, or equivalent) is part of your validation flow today, it stays part of it.
- Require a named human reviewer of record. Someone with their initials on the change log actually read and understood the logic, not just approved the diff. This matters as much for audit trail as for catching mistakes.
- Version-control the prompt, not just the output. If a future incident investigation needs to reconstruct why a piece of logic exists, “an AI assistant suggested it based on this prompt” is a very different root-cause finding than “an engineer designed it based on this requirement,” and you want that traceable.
None of this is about rejecting the tools. Rejecting them isn’t realistic — they’re being built into the IDEs your team already uses, and the productivity case for the low-risk categories above is legitimate. The position worth taking is narrower: the line between “safe to accept” and “requires full manual validation” should be drawn by risk classification, not by how confident the output looks or how much time it saved you. An AI assistant that writes a clean, well-commented, syntactically perfect interlock routine that’s missing one fault state is more dangerous than one that produces obviously broken code, because obviously broken code gets caught. Plausible-but-incomplete code is what gets shipped.
Plants that get this right in the next few years will be the ones that wrote their own internal review policy before their engineers had to invent one under deadline pressure. The vendors built a faster way to generate logic. They didn’t build a faster way to validate it — that part is still entirely on you.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
